Help:Editing
Telnet Service Protocol Edit TELNET is a standard protocol. Its status is recommended. Telnet even predates internetworking and the modern IP packet and TCP transport layers. The TELNET protocol provides a standardized interface, through which a program on one host (the TELNET client) may access the resources of another host (the TELNET server) as though the client were a local terminal connected to the server. For example, a user on a workstation on a LAN may connect to a host attached to the LAN as though the workstation were a terminal attached directly to the host. Of course, TELNET may be used across WANs as well as LANs. Most TELNET implementations do not provide you with graphics capabilities. TELNET OPERATION The TELNET protocol is based on three ideas: The Network Virtual Terminal (NVT) concept. An NVT is an imaginary device having a basic structure common to a wide range of real terminals. Each host maps its own terminal characteristics to those of an NVT, and assumes that every other host will do the same. A symmetric view of terminals and processes . Negotiation of terminal options. The principle of negotiated options is used by the TELNET protocol, because many hosts wish to provide additional services, beyond those available with the NVT. Various options may be negotiated. Server and client use a set of conventions to establish the operational characteristics of their TELNET connection via the ``DO, DON'T, WILL, WON'T'' mechanism discussed later in this document.'' The two hosts begin by verifying their mutual understanding. Once this initial negotiation is complete, they are capable of working on the minimum level implemented by the NVT. After this minimum understanding is achieved, they can negotiate additional options to extend the capabilities of the NVT to reflect more accurately the capabilities of the real hardware in use. Because of the symmetric model used by TELNET, both the host and the client may propose additional options to be used. The set of options is not part of the TELNET protocol, so that new terminal features can be incorporated without changing the TELNET protocol (mouse?). All TELNET commands and data flow through the same TCP connection. Commands start with a special character called the Interpret as Command escape character (IAC). The IAC code is 255. If a 255 is sent as data - it must be followed by another 255 Each receiver must look at each byte that arrives and look for IAC. If IAC is found and the next byte is IAC - a single byte is presented to the application/terminal. If IAC is followed by any other code - the TELNET layer interprets this as a command. TELNET BASIC COMMANDS The primary goal of the TELNET protocol is the provision of a standard interface for hosts over a network. To allow the connection to start, the TELNET protocol defines a standard representation for some functions: IP Interrupt Process AO Abort Output AYT Are You There EC Erase Character EL Erase Line SYNCH Synchronize QUIT quit session ' TELNET SERVICE' Telnet Service allows you to check brief or detailed status of any test and folder. Also you can disable and enable tests, reset statistics, force tests to execution and even change some parameters of the tests. HM Telnet Service allows you to start or stop monitoring process, enable or disable alerts, change global macro variables, etc. All data transmission between HostMonitor and Telnet Service is encrypted and password protected; HostMonitor & Telnet Service allow you to setup different user accounts with different sets of permissions; Application can be installed on the HostMonitor's system or can be located on any another system that is accessible by TCP/IP protocol; Telnet Service can be started as a regular application or as a Win32 service. SETTINGS It is very easy to configure Telnet Service: RCI (Remote Control Interface) settings Address: here you should provide an address of the system where HostMonitor is installed (keep the default '127.0.0.1' if HostMonitor and Telnet Service are installed on the same system) Port: please provide TCP port that is used by HostMonitor's Remote Control Interface (1054 by default) Timeout: the maximum amount of time (in seconds) that Telnet Service will keep waiting for the reply from HostMonitor before returning an error response to the client. Telnet server settings Port: TCP port which Telnet Service utilizes to listen for incoming connections from the telnet client (default TCP port for telnet protocol is 23. You may need to change it in case you already have a regular telnet server running on the same system). Application status: set "Active" to activate Telnet service (it will then start listening for incoming connections and will respond to requests from any telnet client). If you start the software as a Win32 service then telnet server will be activated regardless of this option at the system startup. Win32 service mode: This group of controls allows you to check the status of the Windows service, install/uninstall, start or stop the service: Install / Uninstall: this button allows you to install/uninstall software as a Win32 service Start / Stop: this button allows you to start/stop the service TELNET PROTOCOL Telnet protocol is a standard internet protocol enabling terminals and applications to interface over the Internet. This protocol provides the basic rules making it possible to link a client (system composed of a display and keyboard) to a command interpreter (server side). The Telnet protocol is applied on a TCP connection to send data in ASCII format coded over 8 bits between which the Telnet check sequences come. It therefore provides a communication orientated bi-directional system (half-duplex), coded over 8 bits and easy to implement. The Telnet protocol relies on three basic concepts: * The Network Virtual Terminal (NVT) paradigm; * The negotiated options principle; * The rules of negotiation. This is a base protocol, to which certain other protocols from the TCP/IP suite (FTP, SMTP, POP3, ...) are applied. Telnet specifications do not mention authe http://static1.wikia.nocookie.net/filetransferprotocol/images/b/b0/1972_telnet.gifntication because Telnet is totally separated from applications which use it (FTP protocol defines an authentication sequence above Telnet). Additionally, the Telnet protocol is a non secure data transfer protocol, that is the data which it conveys circulates on the network in plain text (in an unencrypted way). When the Telnet protocol is used to connect a remote host to the machine upon which it is implemented as server, this protocol is assigned to port 23. Except for the associated options and negotiation rules, the Telnet protocol specifications are basic. Data transmission through Telnet consists only of transmitting bytes in the TCP flow (the Telnet protocol specifies that data must by default, i.e. if no option specifies to the contrary, be grouped in a buffer before being sent. More precisely this means that by default the data is sent line by line). When byte 255 is transmitted, the following byte must be interpreted as a command. Byte 255 is therefore called IAC (Interpret As Command). The commands are described further on in the document. The basic specifications of the Telnet protocol are available in RFC 854, while the many options are described in RFCs 855 to 861. 'Telnet: History, Purpose, Advantages, Disadvantages' Telnet Protocol In the very earliest days of internetworking, one of the most important problems that computer scientists needed to solve was how to allow someone operating one computer to access and use another as if he or she were connected to it locally. The protocol created to meet this need was called Telnet, and the effort to develop it was tied closely to that of the Internet and TCP/IP as a whole. Even though most Internet users today never invoke the Telnet protocol directly, they use some of its underlying principles indirectly all the time. Every time you send a piece of e-mail, use FTP to transfer a file, or load a Web page, you are using technology based on Telnet. For this reason, the Telnet protocol can made a valid claim to the title of the most historically important application protocol in TCP/IP. In this section, I describe the operation of the Telnet protocol. I begin with an overview and history of the protocol and a discussion of the standards that define it. I describe the general operation of Telnet clients and servers and how connections are made and maintained. I then explain the important concept of the Network Virtual Terminal (NVT), Telnet’s protocol commands, and how interrupts are handled using Telnet’s special synch function. I conclude with a detailed look at Telnet’s options and how they are negotiated. Before gophers, hypertext, and sophisticated web browsers, telnet was the primary means by which computer users connected their machines with other computers around the world. Telnet is a plain ASCII terminal emulation protocol that is still used to access a variety of information sources, most notably libraries and local BBS’s. This report will trace the history and usage of this still popular and widely used protocol and explain where and how it still manages to fit in today. HISTORY AND FUTURE OF TELNET “Telnet” is the accepted name of the Internet protocol and the command name on UNIX systems for a type of terminal emulation program which allows users to log into remote computer networks, whether the network being targeted for login is physically in the next room or halfway around the globe. A common program feature is the ability to emulate several diverse types of terminals–ANSI, TTY, vt52, and more. In the early days of networking some ten to fifteen years ago, the “internet” more or less consisted of telnet, FTP (file transfer protocol), crude email programs, and news reading. Telnet made library catalogs, online services, bulletin boards, databases and other network services available to casual computer users, although not with the friendly graphic user interfaces one sees today. Each of the early internet functions could be invoked from the UNIX prompt, however, each of them used a different client program with its own unique problems. Internet software has since greatly matured, with modern web browsers (i.e. Netscape and Internet Explorer) easily handling the WWW protocol (http) along with the protocols for FTP, gopher, news, and email. Only the telnet protocol to this day requires the use of an external program. Due to problems with printing and saving and the primitive look and feel of telnet connections, a movement is underway to transform information resources from telnet-accessible sites to fully fledged web sites. However, it is estimated that it will still take several years before quality web interfaces exist for all of the resources now currently available only via telnet. Therefore, knowing the underlying command structure of terminal emulation programs like telnet is likely to remain necessary for the networking professional for some time to come. ADVANTAGES AND DISADVANTAGES OF TELNET The chief advantage to the telnet protocol today lies in the fact that many services and most library catalogs on the Internet remain accessible today only via the telnet connection. Since telnet is a terminal application, many see it as a mere holdover from the days of mainframe computers and minicomputers. With the recent interest in $500 Internet terminals may foretell resurgence in this business. Disadvantages include the aforementioned problems that telnet tends to have printing and saving files and its primitive look and feel when compared to more modern web browsers. OTHER APPROACHES The functionality of the telnet protocol may be compared with the UNIX “rlogin” command, an older remote command that still has some utility today. Rlogin is a protocol invoked by users with accounts on two different UNIX machines, allowing connections for certain specified users without a password. This requires setting up a “.rhosts” or “/etc/hosts.equiv” file and may involve some security risks, so caution is advised. Using telnet instead of the rlogin command will accomplish the same results, but the use of the rlogin command will have the effect of saving keystrokes, particularly if it is used in conjunction with an alias. WHAT ARE THE BENEFITS OF TELNET AND HOW TO YOU USE THEM? The following are some of the benefits of telnet: It allows a user to log in to a remote computer and execute programs. It is a common utility in the TCP/IP protocol suite and is thus as widely · implemented many platforms. Therefore a telnet client program is usually easily available. It can be used to administer most enterprise class network equipment by connecting to the device and executing built-in configuration and status programs. It may be used to debug network services such as SMTP, IRC, HTTP, FTP or POP3. The person testing would use telnet to connect to the service and so send commands to the server and consequently examine the responses in order to make analyses. How to exploit the benefits is a little involved and problem specific. For example, the followinglinks and indicated sections show how it may be used to debug SMTP and POP3 e-mail protocols: See the "Sample Communications" section ofhttp://en.wikipedia.org/wiki/SMTP. Accessed: 2009-01-02. See the "Dialog Example" section ofhttp://en.wikipedia.org/wiki/Post_Office_Protocol. Accessed: 2009-01-02. Sources:http://en.wikipedia.org/wiki/Telnet. Accessed: 2009-01-02. http://www.answers.com/main/ntquery?s=telnet. Accessed: 2009-01-02. You can weld with it. solder, cook, stay warm and comfortable, make light with it. the heat from a fuel explosion runs a car. the list goes on forever, Heat even makes it rain. it saves the usage of energy and it does not affect the evironment Telnet Connections and Client/Server Operation Telnet’s overall function is to define a means by which a user or process on one machine can access and use another machine as if it were locally connected. This makes Telnet inherently client/server in operation, like so many other application protocols in TCP/IP. Usually, the Telnet client is a piece of software that acts as an interface to the user, processing keystrokes and user commands and presenting output from the remote machine. The Telnet server is a program running on a remote computer that has been set up to allow remote sessions. TCP Sessions and Client/Server Communication Telnet is used for the interactive communication of data and commands between client and server over a prolonged period of time, and is thus strongly based on the concept of a session. For this reason, Telnet runs over the connection-oriented Transmission Control Protocol (TCP). Telnet servers listen for connections on well-known TCP port number 23. When a client wants to access a particular server, it initiates a TCP connection to the appropriate server, which responds to set up a TCP connection using the standard TCP three-way handshake. The TCP connection is maintained for the duration of the Telnet session, which can remain alive for hours, days, or even weeks at a time. The quality of service features of TCP guarantee that data is received reliably and in order, and ensures that data is not sent at too high a rate for either client or server. A machine offering Telnet service can support multiple simultaneous sessions with different users, keeping each distinct by identifying it using the IP address and port number of the client. Since TCP is a full-duplex protocol, both client and server can send information at will over the Telnet session. By default, both devices begin by using the standard Telnet Network Virtual Terminal (NVT) method for encoding data and control commands. They can also negotiate the use of Telnet options to provide greater functionality for the session. While option negotiation can occur at any time, it is normal for there to be a “burst” of such option exchanges when a Telnet session is first established, and only occasional option command exchanges thereafter. With the TCP connection in place and the Telnet session active, the client and server software begin their normal jobs of interfacing the user to the remote host. To the user, the Telnet session appears fundamentally the same as sitting down at a terminal directly connected to the remote host. In most cases, the server will begin the user’s session by sending a login prompt to ask for a user name and password. The Telnet client will accept this information from the user and send it to the server. Assuming the information is valid, the user will be logged in and can use the host in whatever manner his or her account authorizes. As mentioned in the Telnet overview, even though the protocol is classically intended for remote login, it need not be used in this manner. The administrator of the computer that is running the Telnet server determines how it is to be used on that machine. As just one example, a Telnet server can be interfaced directly to a process or program providing a service. I can recall years ago using an Internet server that provided weather information to the public using Telnet. After using the protocol to connect to that machine, you would be presented not with a login prompt, but a menu of weather display options. Of course today, the Web has replaced most of such facilities, as it is far better-suited to this type of information retrieval. Use of Telnet To Access Other Servers The Telnet NVT representation is used by a variety of other protocols such as SMTP and HTTP. This means that the same Telnet client that allows you to access a Telnet server can be used to directly access other application servers. All you need to do is specify the port number corresponding to the service. For example, this command will allow you to directly interface to a Web server: You will not receive a login prompt, but instead the server will wait for you to send an HTTP Request message, as if you were a Web browser. If you enter a valid request, the server will send you an HTTP Response message. Used in this way, Telnet can be very valuable as a diagnostic tool. Telnet Communications Model and the Network Virtual Terminal (NVT) (Page 1 of 4) At its heart, Telnet is a rather simple protocol. Once a TCP connection is made and the Telnet session begins, the only real task that the client and server software has is to capture input and output, and redirect it over the network. So, when the user types a key on his local terminal, the Telnet client software captures it and sends it over the network to the remote machine. There, the Telnet server software sends it to the operating system, which treats it as if it had been typed locally. When the operating system produces output, the process is reversed: Telnet server software captures the output and sends it over the network to the user’s client program, which displays it on the printer or monitor. To invoke two well-known clichés, I could say that this “looks good on paper”, but that “the devil is in the details”. This simplified implementation would only work if every computer and terminal used the exact same hardware, software and data representation. Of course, this is far from the case today, and was even worse when Telnet was being developed. The Problem of Differing Representations Computers back in the “good old days” were highly proprietary, and not designed to interoperate. They differed in numerous ways, from the type of keyboard a terminal used and the keystrokes it could send, to the number of characters per line and lines per screen on a terminal, to the character set used to encode data and control functions. In short, computer A'' was designed to accept input in a particular form from its own terminals, and not those of Computer''B. This is actually a fairly common issue in the world of networking, and one to which we can draw a real-world analogy to help explain the problem and how it may be solved. Suppose that an important international conference was attended by 30 ambassadors from different nations, each of which had one assistant. Every ambassador and assistant pair spoke only their own language and thus could only speak to each other—just like a computer and terminal designed to interface only to each other. To allow the assistant from one country to speak to the ambassador from the others, one solution would be to train the assistants to speak the languages of all the other attending nations. Back in the computing world, this would be like defining the Telnet protocol so that every Telnet client software implementation understood how to speak to every computer in existence. In both cases, this would work, but would be quite impractical and difficult to do. An alternative approach is to define a single common language and have all the ambassadors and assistants learn it. While this would require some work, it would be a lot less than requiring people to learn dozens of languages. Each ambassador and assistant would speak both his or her native language and this chosen common language. Each could communicate with all of the others using this common language, without having to know all of the languages that might be used by anyone at the conference. Even more importantly, if an ambassador and assistant showed up at the conference speaking a new, 31st language, all the other delegates wouldn’t need to learn it. (Page 2 of 4) The Network Virtual Terminal Telnet uses an approach similar to the analogy described above for dealing with its problem of hardware and software compatibility. Rather than having terminals and hosts communicate using their various native “languages”, all Telnet clients and servers agree to send data and commands that adhere to a fictional, “virtual” terminal type call the Network Virtual Terminal (NVT). The NVT defines a set of rules for how information is formatted and sent, such as character set, line termination, and how information about the Telnet session itself is sent. Each Telnet client running on a terminal understands both its native language and NVT. When information is entered by the user on his or her local terminal, it is converted to NVT for transmission over the network in NVT form. When the Telnet server receives this information, it translates it from NVT to the format that the remote host expects to receive it. The identical process is performed for transmissions from the server to the client, in reverse. This is illustrated in Figure 320. The NVT is defined to consist of a logical “keyboard” for input and a logical “printer” for output (the age of the protocol is reflected in these terms; decades ago there were no monitors, all output was on paper). NVT uses the 7-bit United States ASCII (USASCII) character set. Each character is encoded using one 8-bit byte. Note however that a client and server can use Telnet options to negotiate other data representations, including the transmission of either extended ASCII or even full 8-bit binary data. (Page 3 of 4) NVT ASCII Control Codes Regular ASCII consists of 95 regular, “printable” characters (codes 32 through 126) and 33 control codes (0 through 31 and 127). The Telnet standard specifies that the output device must be able to handle all the printable characters, and it mandates how several of the other common ASCII control codes should be interpreted. Of these codes, three (0, 10 and 13) are required to be accepted by all Telnet software; five others are optional, but if supported, must be interpreted in a manner consistent with the Telnet specification. They are all described in Table 280. (Page 4 of 4) End-of-Line Representations The Telnet NVT scheme defines the combination of the carriage return (“CR”) and line feed (“LF”) characters to represent the end of a line of ASCII text. The literal meaning of these two characters is “return to the left margin” (from the “CR”) and “go to the next line” (from the “LF”). However, NVT treats the “CR+LF” sequence as more than just two independent characters; they are taken collectively to define a logical “end of line” character. This is necessary because not all terminal types define an end of line using both “CR” and “LF”. Translation of end-of-line characters between the native and NVT formats is one of the functions that Telnet client and server software must perform to ensure compatibility between terminals and hosts. Half-Duplex and Full-Duplex Modes Another artifact of the age of Telnet is that for maximum compatibility, the Network Virtual Terminal specification is designed under the assumption of half-duplex operation: only one device can transmit at a time. A device that is sending data is supposed to end its transmission with the special Telnet Go Ahead command, telling the other device that it may now transmit (the next topic describes Telnet protocol commands). This is similar to how people using walkie-talkies end each transmission with “over” to tell their partner that they may now respond. Of course, modern networks operate in a full-duplex mode, and using half-duplex communication would be needlessly inefficient. In most cases the Telnet client and server agree to use an option (Suppress Go Ahead) that eliminates the need to send this command. However, having this as the default is a good example of how NVT acts as a “least common denominator” in Telnet, in case the simpler operating mode is needed by either device. Princess Janine B. Mendoza\ http://support.microsoft.com/kb/231866 Telnet Options Options give the client and server a common view of the connection. They can be negotiated at any time during the connection by the use of commands. They are described in separate RFCs. The following are examples of common options: Decimal code Name RFC 3 suppress go ahead 858 5 status 859 1 echo 857 6 timing mark 860 24 terminal type 1091 31 window size 1073 32 terminal speed 1079 33 remote flow control 1372 34 linemode 1184 36 environment variables 1408 Either end of a Telnet conversation can locally or remotely enable or disable an option. The initiator sends a 3-byte command of the form: IAC Type of Operation Option The response is of the same form. Operation is one of: Description Decimal Code Action WILL 251 Sender wants to do something. WONT 252 Sender doesn't want to do something. DO 253 Sender wants the other end to do something. DONT 254 Sender wants the other not to do something. Associated with each of the these commands are various possible responses: Sender Sent Receiver Responds Implication WILL DO The sender would like to use a certain facility if the receiver can handle it. Option is now in effect. WILL DONT Receiver says it cannot support the option. Option is not in effect. DO WILL The sender says it can handle traffic from the sender if the sender wishes to use a certain option. Option is now in effect. DO WONT Receiver says it cannot support the option. Option is not in effect. WONT DONT Option disabled. DONT is only valid response. DONT WONT Option disabled. WONT is only valid response. For example, if the sender wants the other end to suppress go-ahead, it would send the byte sequence: IAC WILL Suppress Go Ahead The final byte of the 3-byte sequence identifies the required action. Some option's values need to be communicated after support of the option has been agreed. This is done using sub-option negotiation. Values are negotiated using value query commands and responses in the following form: IAC SB option code 1 IAC SE and IAC SB option code 0 IAC SE For example, if the client wants to identify the terminal type to the server, the following exchange might take place: CLIENT IAC WILL Terminal Type SERVER IAC DO Terminal Type CLIENT IAC SB Terminal Type 1 IAC SE SERVER IAC SB Terminal Type 0 V T 2 2 0 IAC SE The first exchange establishes that terminal type (option number 24) is handled, the server then enquires of the client what value it wishes to associate with the terminal type. The sequence SB,24,1 implies sub-option negotiation for option type 24, value required (1). The IAC,SE sequence indicates the end of this request. The response IAC,SB,24,0,'V'... implies sub-option negotiation for option type 24, value supplied (0), the IAC,SE sequence indicates the end of the response (and the supplied value). The encoding of the value is specific to the option but a sequence of characters, as shown above, is common. DESCRIPTION OF TELNET OPTIONS Many of those listed are self-evident, but some call for more information. Suppress Go Ahead The original Telnet implementation defaulted to half duplex operation. This means that data traffic could only go in one direction at a time and specific action is required to indicate the end of traffic in one direction and that traffic may now start in the other direction. similar to the use of "roger" and "over" by amateur and CB radio operators. The specific action is the inclusion of a GA character in the data stream. Modern links normally allow bi-directional operation and the "suppress go ahead" option is enabled. Echo The echo option is enabled, usually by the server, to indicate that the server echos every character it receives. A combination of "suppress go ahead" and "echo" is called character-at-a-time mode meaning that each character is separately transmitted and echoed. There is an understanding known as kludge-line mode, which means that if either "suppress go ahead" or "echo" is enabled but not both, then Telnet operates in line-at-a-time mode meaning that complete lines are assembled at each end and transmitted in one "go". Linemode This option replaces and supersedes the line mode kludge. Remote Flow Control This option controls where the special flow control effects of Ctrl+S or Ctrl+Q are implemented. Telnet Control Functions The Telnet protocol includes a number of control functions. These are initiated in response to conditions detected by the client (usually certain special keys or key combinations) or server. The detected condition causes a special character to be incorporated in the data stream. Interrupt Process This is used by the client to cause the suspension or termination of the server process. Typically, the user types Ctrl+C on the keyboard. An IP (244) character is included in the data stream. Abort Output This is used to suppress the transmission of remote process output. An AO (238) character is included in the data stream. Are You There This is used to trigger a visible response from the other end of the connection to confirm the operation of the link and the remote process. An AYT (246) character is incorporated in the data stream. Erase character This is sent to the display to tell it to delete the immediately preceding character from the display. An EC (247) character is incorporated in the data stream. Erase line This option causes the deletion of the current line of input. An EL (248) character is incorporated in the data stream. Data Mark Some control functions such as AO and IP require immediate action and this may cause difficulties if data is held in buffers awaiting input requests from a (possibly misbehaving) remote process. To work around this problem, a DM (242) character is sent in a TCP Urgent segment, this tells the receiver to examine the data stream for "interesting" characters such as IP, AO, and AYT. This is known as the Telnet synchronization mechanism. A DM not in a TCP Urgent segment has no effect. Summary Telnet offers users the capability of running programs remotely and facilitates remote administration. Telnet is available for practically all operating systems and eases integration in heterogeneous networking environments.